1. Field of the Invention
The present invention relates to encryption. More specifically, the present invention relates to a method and an apparatus for encrypting data to facilitate resource savings and detection of tampering.
2. Related Art
In order to securely store data, administrators often encrypt the data before storing the data in a database. However, encrypting data typically expands the data beyond its original size. This expansion is usually associated with three factors: (1) the use of an initialization vector or salt; (2) the use of an integrity check; and (3) block justification of (padding of) the data. The exact factors will depend on the type of chaining and encryption that is used on the data.
During block justification, input data is padded to a length that is an exact multiple of an encrypted block size. In doing so, various padding methods can be used. Under one commonly used padding technique (PKCS5 padding), the padding can potentially add as much as an entire block length to the encrypted text.
The purpose of the initialization vector is to “randomize” the plaintext data. The initialization vector is also an example of “salt”, which is intended to describe the act of modifying messages to make them appear more random. This is particularly useful for plaintext data that comes from a small input set. For example, if you are storing patient data in a database table, and you have a column that indicates if the patient is HIV positive, there are only two possible values, “yes” and “no.” Thus, if the same encryption key is used for the table, without using an initialization vector to randomize the field values, it is possible to determine which patients have the same value in the HIV column because only two possible cipher-texts corresponding to the two-possible plaintext values would exist in the table.
The primary purpose of the integrity check is to prevent meaningful tampering of the cipher-text. Specifically, you do not want someone to be able to flip one or more bits in an encrypted block to obtain a meaningful different plaintext value when you decrypt the new encrypted block. For example, if the data is salary data, an attacker should not be able to flip one or more bits in an encrypted block to produce a new, valid, plaintext salary value when the block is decrypted. This attack will generally fail if an integrity check is used because the new plaintext will no longer match the integrity check. One typical way in which the integrity check is performed is by saving a hash of the data along with the encrypted data. In this case, if the data is subsequently tampered with, a hash which is generated from the new data will no longer match the existing hash.
In order to ensure that encrypted data is safe from the problems listed above, all of the above steps are typically used to secure encrypted data. However, as previously mentioned, all of these steps can lead to an expansion in the size of the data. If the dataset includes many small values, such as while encrypting financial information, this can cause significantly more data-storage resources to be used than storing the data in plaintext. Furthermore, some of these steps are computationally expensive. For example, performing a hashing function on thousands of small values can consume a significant amount of resources.
Hence, what is needed is a method and an apparatus for providing secure storage of data that is resistant to the types of attacks described above, but without the problems described above.